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(57) Abstract: An approach for providing a quality indicator in support of a communication session between a near end station (101) 
q and a far end station (103) over a data network (105). Th e quality of the communication session in a direction of the near end station 

(10n sending to the far end station JJ.0S) is .det ermined . A message containing statistics associated with the communication session 
Q is transmitted according to a prescribed protocol to the near end station (101) to notify the near end station (101) of the quality of the 
£>> communication session. The prescribed protocol supports real-time data exchange. The present invention has particular applic ability 
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COMMUNICATION SESSION QUALITY INDICATOR 
FIELD OF THE INVENTION 

[01) The present invention relates to a communications system, and is more particularly 
related to call processing over a data network. 

BACKGROUND OF THE INVENTION 

[02] The popularity and convenience of the Internet has resulted in the reinvention of 
traditional telephony services. These services are offered over a packet switched network with 
minimal or no cost, to the users. IP (Internet Protocol) telephony, thus, have found significant 
success, particularly in the long distance market. In general, IP telephony, which is also referred 
to as Voice-over- IP (VOIP), is the conversion of voice infonnation into data packets that are 
transmitted over an IP network. Users also have turned to IP telephony as a matter of 
convenience in that both voice and data services are accessible through a single piece of 
equipment, namely a personal computer. The continual integration of voice and data services 
further fuels this demand for IP telephony applications. 

[03| In the traditional circuit switched PSTN (public switched telephone network) 
environment, the forward and reverse voice paths of a telephone call between a near end station 
and a far end station always traverse the same set of switches and network elements. As a result, 
any degradation or interference in one call direction is often mirrored in the reverse direction 
with respect to the near end station and the far end station. For example, if a near end station 
hears static during the call, it is highly likely that the other party is experiencing the same 
problem. Accordingly, each party to the call is implicitly notified that the quality of the call is 
poor; as a result, the near end station may take appropriate action, such as hanging up and re- 
establishing the call, instead of continuing with the conservation (despite the fact that the other 
party may not be able to hear any of the discussion). It is recognized that such a feedback 
mechanism is currently lacking with respect to voice calls over the Internet. 
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[04] With VOIP technology, the voice or media path between a near end station and a far end 
station in the forward and reverse directions are likely to be different, traversing different 
network elements and physical circuits with each transmission. As a result, it is entirely possible 
that a near end station's media packets arrive without any problems, while the far end station's 
media packets (in the opposite direction) may be lost or delayed. Therefore, a feedback 
mechanism analogous to that of the traditional telephone call over the PSTN cannot be effected. 
Without such notification, the near end station cannot take corrective action, such as requesting a 
guaranteed quality of service (QoS) on the call, or attempt to call at a later time. 
[05] Therefore, there is a need for an approach for providing notification to convey quality of 
a communication session. 
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SUMMARY OF THE INVENTION 

[061 These and other needs are addressed by the present invention in which a feedback 
mechanism, which may be visual or audio, is introduced to notify a near end station of the 
quality of a voice communication session over a data network (e.g., an IP-based (Internet 
Protocol) network). The feedback mechanism is based upon the quality statistics that are 
conveyed via a real-time communications protocol, such as Real -time Transport Control Protocol 
(RTCP). 

[07] In one aspect of the present invention, a method is provided for supporting a 
communication session between a near end station and a far end station over a data network. The 
method includes determining quality of the communication session in a direction of the near end 
station to the far end station. The method also includes transmitting a message according to a 
prescribed protocol to the near end station to notify the near end station of the quality of the 
communication session, wherein the prescribed protocol supports real-time data exchange. 
[08] Another aspect of the present invention, a network device is provided for supporting a 
communication session between a near end station and a far end station over a data network. The 
device includes a processor that is configured to determine quality of the communication session 
in a direction of the near end station to the far end station. The device also includes a 
communications interface that is coupled to the processor and is configured to transmit a 
message according to a prescribed protocol to the near end station to notify the near end station 
of the quality of the communication session, wherein the prescribed protocol supports real- time 
data exchange. 

[09] Another aspect of the present invention, a system for providing telephony services over a 
data network is disclosed. The system includes a first station that has connectivity with the data 
network and is configured to initiate establishment of a communication session over the data 
network. The system includes a second station that is configured to acknowledge the 
communication session with the first station, wherein the second station is further configured to 
determine quality of the communication session in a direction from the second station to the first 
station, and to transmit a message according to a prescribed protocol to the first station to notify 
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the first station of the quality of the communication session, the prescribed protocol supporting 
real-time data exchange. 

[10J Another aspect of the present invention, a device for supporting a communication session 
between a near end station and a far end station over a data network is disclosed. The device 
includes means for determining quality of the communication session in a direction of the near 
end station to the far end station; and means for transmitting a message according to a prescribed 
protocol to the near end station to notify the near end station of the quality of the communication 
session. The prescribed protocol supports real-time data exchange. 

(Ill In yet another aspect of the present invention, a computer-readable medium carrying one 
or more sequences of one or more instructions for supporting a communication session between a 
near end station and a far end station over a data network is disclosed. The one or more 
sequences of one or more instructions include instructions which, when executed by one or more 
processors, cause the one or more processors to perform the step of determining quality of the 
communication session in a direction of the near end station to the far end station. Another step 
includes transmitting a message according to a prescribed protocol ttKthe near end station to 
notify the near end station of the quality of the communication session. The prescribed protocol 
supports real-time data exchange. 

1 1 21 Still other aspects, features, and advantages of the present invention are readily apparent 
from the following detailed description, simply by illustrating a number of particular 
embodiments and implementations, including the best mode contemplated for carrying out the 
present invention. The present invention is also capable of other and different embodiments, and 
its several details can be modified in various obvious respects, all without departing from the 
spirit and scope of the present invention. Accordingly, the drawing and description are to be 
regarded as illustrative in nature, and not as restrictive. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

[13J The present invention is illustrated by way of example, and not by way of limitation, in 
the figures of the accompanying drawings and in which like reference numerals refer to similar 
elements and in which: 

|14J FIG. 1 is a diagram of a communications system that is capable of providing a quality 
indicator of a voice^co mmunication jessio^established over a data network, according to an 
embodiment of the present invention; 

(15] FIG. 2 is a diagram of an exemplary protocol architecture employed in the system of FIG. 

i; 

[16] FIG. 3 is a diagram of a header format of the Real-Time Transport Protocol that i s 
utilized in the system of FIG. 1 ; 

|171 FIG. 4 is a diagram of a format of the sender report Real-Time Transport Control 
Protocol that is employed in the system of FIG. 1; 

|18| FIG. 5 is a flowchart of a process for providing session quality indication to a near en d 
station, according to an embodiment of the present invention; 

[19] FIGs. 6A and 6B are diagrams of a LED (Light Emitting Diode) type display and a pop- 
up menu, respectively, to indicate the quality of a communication session, according to an 
embodiment of the present invention; and 

120] FIG. 7 is a diagram of a computer system that can be used to implement an embodiment 
of the present invention. 
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DESCRIPTION OF THE PREFERRED EMBODIMENT 

[21] In the following description, for the purposes of explanation, numerous specific details 
are set forth in order to provide a thorough understanding of the present invention. It is apparent, 
however, to one skilled in the art that the present invention may be practiced without these 
specific details or with an equivalent arrangement. In other instances, well-known structures and 
devices are shown in block diagram form in order to avoid unnecessarily obscuring the present 
invention. 

[22J Although the present invention is discussed with respect to the Session Initiation Protocol 
(SIP), it should be appreciated that one of ordinary skill in the art would recognize that the 
present invention has applicability to other equivalent communication protocols. 
[23| FIG. 1 shows a diagram of a communications system that is capable of providing a 
quality indicator of a voice communication session established over a data network, according to 
an embodiment of the present invention. In particular, the communication system 1 00 supports 
IP telephony services among multiple user agents 101, 103, according to the Session Initiation 
Protocol (SIP). 

|24] SIP has emerged to address the signaling of calls over an IP network 105. As an end-to- 
end protocol, SIP advantageously permits the end nodes with the capability to control call 
processing. By contrast, traditional telephony services are totally controlled by the intermediate 
network components; that is, the switches have full control over call establishment, switching, 
and call termination. In the SIP architecture, it is sometimes desirable for an intermediate 
network element to control the call processing. For example, codec (coder/decoder) 
incompatibility may require network intervention to ensure that the exchange of packets are 
meaningful. 

(251 As shown, the user agent 103 is connected to the Public Switched Telephone Network 
(PSTN) 107. In this example, the user agent 101 has connectivity to a Private Branch Exchange 
(PBX), which in turn, passes calls through to the PSTN 107. Because the PSTN 107 has 
connectivity to the IP network 1 05, communication among voice statio ns (not shown) that are 
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serviced through the PSTN 107, and personal computers that are attached to the IP network 105 
can be established (e.g., Voice over IP (VOIP)). 

[26] Attention is now drawn to transmission of voice calls over the IP network 105. Four 
possible scenarios exist with the placement of a VOIP call: (1) phone-to-phone, (2) phone-to- 
PC, (3) PC-to-phone, and (4) PC-to-PC. In the first scenario of phone -to-phone call 
establishment, a voice station is switched through PSTN 107 by a switch to a VOIP gateway 113, 
which forwards the call through the IP network 105. The packetized voice call is then routed 
through the IP network 105, exiting the IP network 105 at an appropriate point to enter the PSTN 
107 and terminates at a voice station. Under the second scenario, a voice station places a call to 
PC through a switch to the PSTN 107. This voice call is then switched by the PSTN 107 to a 
VOIP gateway 113, which forwards the voice call to a PC via the IP network 105. The third 
scenario involves a PC that places a call to a voice station. Using a voice encoder, the PC 
introduces a stream of voice packets into the IP network 105 that are destined for a VOIP 
gateway 113. A VOIP gateway 113 converts the packetized voice information into a POTS 
(Plain Old Telephone Service) electrical signal, which is circuit switched to the voice station. 
Lastly, in the fourth scenario, a PC establishes a voice call with a PC; in this case, packetized 
voice data is transmitted from the PC via the IP network 105 to another PC, where the packetized 
voice data is decoded 

[27] The system 100 employs SIP to exchange messages. A detailed discussion of SIP and its 
call control services are described in IETF RFC 2543 and IETF Internet draft "SIP Call Control 
Services", June 17, 1999; both of these documents are incorporated herein by reference in their 
entireties. SIP messages are either requests or responses. The user agents 101, 103 may behave 
as either a user agent client (UAC) or a user agent server (UAS), depending on the services that 
the system 100 is executing. In general, a user agent client issues requests, while a user agent 
server provides responses to these requests. 

128] SIP defines six types of requests, which are also referred to as methods. The first method 
is the INVITE method, which invites a user to a conference. The next method is the ACK 
method, which provides for reliable message exchanges for invitations in that the client is sent a 
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confirmation to the INVITE request. That is, a successful SIP invitation includes an INVITE 
request followed by an ACK request. 

(291 Another method is the BYE request, which indicates to the UAS that the call should be 
released. In other words, BYE terminates a connection between two users or parties in a 
conference. The next method is the OPTIONS method; this method solicits information about 
capabilities and does not assist with establishment of a call. Lastly, the REGISTER provides 
information about a user's location to a SIP server. 

|30] As seen in FIG. 1, the user agents 101, 103 co mmunicate over a communications channel 
111 that is established, for example, using SIP. Because SIP can be used for signaling, a media 
session transported using schemes such as RTP (Real- Time Transport ProtocoiyUDP (User 
Datagram Protocol), RTP/TCP (Transmission Control Protocol), RTP/SCTP (Stream Control 
Transmission Protocol), and AAL (ATM Adaptation Layer)/ATM (Asynchronous Transfer 
Mode) among many others; this service allows calling between schemes in an efficient way. The 
channel 111 includes two media paths 111a, 111b, which may traverse different network 
elements. 

[31] RTP operates with a companion protocol, RTCP, to provide visual feedback to the near 
end station on the quality of his transmitted media (the quality of his received media is readily 
available just by listening to the sound). As used herein, the terms "near end station" and "far 
end station" refer to the relative relationship between two stations (e.g., agents, entities, parties, 
etc.) in communication, without regard to the station that initiates the communication session. 
RTCP packet exchange allows the other end of the conversation to report back the quality. 
Because VOIP systems employ either SIP or H.323, which both support RTP, RTCP can be 
readily used. To appreciate the present invention, a brief description of the SIP protocol 
architecture is now described with respect to FIG. 2. 

[32] FIG. 2 is a diagram of an exemplary protocol architecture employed in the system of FIG. 
1. The layered nature of the architecture provides protocol separation and independence, 
whereby one protocol can be exchanged or modified without affecting the other higher layer or 
lower layer protocols. It is advantageous that the development of these protocols can occur 
concurrently and independently. 
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(33] The foundation of the architecture rests with the IP layer 201 . The IP layer 201 provides 
an unreliable, connectionless data delivery service at the network level. The service is 
''unreliable" in the sense that the delivery is on a "best effort" basis; that is, no guarantees of 
packet delivery are made. IP is the de facto Internet working protocol standard. Current 
standards provide two versions of IP: Version 4 and Version 6. One of the key differences 
between the versions concerns addressing; under Version 4, the address fields are 32 bits in 
length, whereas in Version 6, the address field has been extended to 128 bits. 
[34] Above the IP layer 201 are the TCP (Transmission Control Protocol) 203 and the UDP 
(User Datagram Protocol) 205. The TCP layer 203 provides a connection-oriented protocol that 
ensures reliable delivery of the IP packets, in part, by performing sequencing functions. This 
sequencing function reorders any IP packets that arrive out of sequence. In contrast, the User 
Datagram Protocol (UDP) 205 provides a connectionless service that utilizes the IP protocol 201 
to send a data unit, known as a datagram. Unlike TCP 203, UDP 205 does not provide 
sequencing of packets, relying on the higher layer protocols to sort the information. UDP 205 is 
preferable over TCP 203 when the data units are small, which saves processing time because of 
the minimal reassembly time. One of ordinary skill in the art would recognize that embodiments 
of the present invention can be practiced using either TCP 203 or UDP 20 5, as well as other 
equivalent protocols. 

[35] The next layer in the IP telephony architecture of FIG. 2 supplies the necessary IP 
telephony signaling and includes the H.323 protocol 207 and the Session Initiation Protocol 
(SIP) 209. The H.323 protocol 207, which is promulgated by the International 
Telecommunication Union (ITU), specifies a suite of protocols for multimedia communication. 
SIP 209 is a competing standard that has been developed by the Internet Engineering Task Force 
(IETF). SIP 209 is a signaling protocol that is based on a client -server model. It should be noted 
that both the H.323 protocol 207 and SIP 209 are not limited to IP telephony applications, but 
have applicability to multimedia services in general. In the preferred embodiment of th e present 
invention, SIP 209 is used to create and terminate voice calls over an IP network 105. However, 
it is understood that one of ordinary skill in the art would realize that the H.323 protocol 207 and 
similar protocols can be utilized in lieu of SIP 209. Above SIP 209 is the Session Description 
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Protocol (SDP) 211, which provides information about media streams in the multimedia 
sessions, as to permit the recipients of the session description to participate in the session. 
[36] As seen in FIG. 2, SIP 209 can utilize either TCP 203 or UDP 205. However, UDP 205 
is adopted in the preferred embodiment of the present invention. Similar to other IETF protocols 
(e.g., the simple mail transfer protocol (SMTP) and Hypertext Transfer Protocol (HTTP)), SIP 
209 is a textual protocol. As indicated earlier, SIP 209 is a client -server protocol, and as such, 
clients generate requests that are responded to by the servers. 

[37] Further, RTP 213 and the auxiliary protocol, RTCP 215, reside above the TCP 203 and 
UDP 205 layers. For example, UDP 205 utilizes the multiplexing function of RTP 213. RTP 
and RTCP packets are usually transmitted using UDP/IP service. RTP 213 and RTCP 215 are 
more fully described in FIGs. 3 and 4. 

[38] FIG. 3 shows a diagram of a header format of the Real-Time Transport Protocol that is 
utilized in the system of FIG. I. As indicated above, the Real-Time Transport Protocol (RTP) is 
an IP-based protocol, which supports real-time data transmissions (e.g., video and audio 
streams). RTP provides such services as time reconstruction, loss detection, security, and content 
identification, which are well-suited to support Internet telephony. RTP is detailed in IETF RFC 
1889, entitled "RTP: A Transport Protocol for Real- Time Applications", and RFC 1890, entitled 
"RTP Profile for Audio and Video Conferences with Minimal Control"; both of which are 
incorporated herein by reference their entireties. 

[39] RTP may be implemented within an application. To set up an RTP session, the 
application defines a particular pair of destination transport addresses (one network address plus 
a pair of ports for RTP and RTCP). In a multimedia session, each medium is carried in a 
separate RTP session, with its own RTCP packets reporting the reception quality for that session. 
For example, audio and video would travel on separate RTP sessions, enabling a receiver to 
select whether or not to receive a particular medium. 

140] An audio-conferencing scenario presented in RFC 1889 illustrates the use of RTP. 
Suppose each participant sends audio data in segments of 20 ms duration. Each segment of audio 
data is preceded by an RTP header, and then the resulting RTP message is placed in a UDP 
packet. The RTP header indicates the type of audio encoding that is used, e.g., PCM (Pulse Code 
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Modulation). Users can opt to change the encoding during a conference in reaction to network 
congestion or, for example, to accommodate low-bandwidth requirements of a new conference 
participant. Timing information and a sequence number in the RTP header are used by the 
receivers to reconstruct the timing produced by the source, so that in this example, audio 
segments are contiguously played out at the receiver every 20 ms. 

[41] As seen in FIG. 3, the header of an RTP packet is 16 octets in length, in which the first 12 
octets are present in every RTP packet. A version field (V) 301 identifies the version of RTP. A 
1-bit padding (P) field 303 is set, if the packet contains one or more additional padding octets at 
the end which are not part of the payload. An extension (X) field 305, which is 1 bit, is set to 
indicate that the header is followed by exactly one header extension. A Contributing Source 
(CSRC) count (CC) field 307 specifies the number of CSRC identifiers that follow the fixed 
header; CSRCs are more fully described below. A 1-bit marker (M) field 309 permits significant 
events, such as frame boundaries, to be marked in the packet stream. A payload type (PT) field 
311 is 7 bits in length and identifies the format of the RTP payload. 

[42] RTP supports end-to-end transport of real-time data via a number of mechanisms, which 
include timestamping and sequence numbering. A 16 -bit sequence number field 313 tracks the 
number of RTP packets that are sent. This sequence number field 313 may be used by the 
receiver to detect packet loss and to restore packet sequence. 

[431 A timestamp field 315 captures the sampling instant of the first octet in the RTP data 
packet; the timestamp information permits synchronization and jitter calculations. The sender 
sets the timestamp according to the instant the first octet in the packet was sampled. After 
receiving the data packets, the receiver uses the timestamp to reconstruct the original timing. As 
mentioned, the timestamp is also used to synchronize different types of data streams (e.g., audio 
and video data). 

[44] Further, a RTP includes a synchronization source (SSRC) identifier field 317, which 
provides unique identification of synchronization sources within an identical RTP session. The 
SSRC field 317 informs a receiving application the origin of the data. A contributing source 
(CSRC) identifier field 319 accommodates 0 to 15 items and identifies the contributing sources 
for the payload contained in the packet; the CC field 307 (described above) indicates the number 
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of identifiers in the CSRC field 319. The CSRC identifiers are inserted by mixers, using the 
SSRC identifiers of contributing sources. 

[45] PIG. 1 shows a diagram of a format of the sender report Real-Time Transport Control 
Protocol that is employed in the system of FIG. 1 . RTCP is a control protocol designed to 
operate in conjunction with RTP, and is detailed in IETF RFCs 1889 and 1890. In an RTP 
session, the sender and receiver periodically transmit RTCP packets to convey feedback on the 
quality of the data delivery. RFC 1889 defines five RTCP packet types to carry control 
information: receiver report (RR), sender report (SR), source description (SDES) items, indicates 
end of participation (BYE), and application specific functions (APP). Participants that are not 
active senders generate the receiver reports. The RR packets contain reception quality feedback 
about data delivery, including the highest packets number received, the number of packets lost, 
inter-arrival jitter, and timestamps to calculate the round-trip delay between the sender and the 
receiver. The sender reports are generated by active senders; these reports provide quality 
feedback as in RR, along with information about the sender (e.g., information on inter-media 
synchronization, cumulative packet counters, and number of bytes sent). The source description 
items contain information about the sources; e.g., canonical names (CNAME), user's name, 
telephone number, e-mail address and other information. 

[46] RTCP carries a persistent transport-level identifier for an RTP sour ce called the canonical 
name or CNAME. Since the SSRC identifier may change if a conflict is discovered or a program 
is restarted, receivers require the CNAME to keep track of each participant. Receivers also 
require the CNAME to associate multiple data streams from a given participant in a set of related 
RTP sessions, for example to synchronize audio and video. The BYE packet signals the 
termination of a RTP session. 

[47] The above RTCP packets support a number of services. One service is monitoring of the 
Quality of Service (QoS) and congestion control. Notably, RTCP provides feedback to an 
application about the quality of data distribution. As mentioned above, RTP receivers provide 
reception quality feedback using RTCP report packets: the sender report (SR) and receiver report 
(RR). The SR is transmitted by a participant if the participant has sent at least one data packet 
since the last report; otherwise, the RR is issued. The SR and RR include zero or more reception 
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report blocks; a block for each of the synchronization sources from which the receiver has 
received RTP data packets since the last report. It is noted that reports are not issued for 
contributing sources that are listed in the CSRC list. Each reception report block provides 
statistics about the data received from the particular source indicated in that block. It is noted 
that a maximum of 31 reception report blocks may be inserted in an SR or RR packet; thus, RR 
packets may be stacked after the initial SR or RR packet as needed to contain the reception 
reports for all sources heard during the interval since the last report. 

[481 The sender report packet has a header with a format as shown in FIG. 4. Like the RTP 
header (in FIG. 3), a 2-bit version field 401 identifies the version of the RTP, and a 1-bit padding 
(P) field 403 may be set to indicate that the particular RTCP packet contains additional padding 
octets. A reception report count (RC) field 405 specifies the number of reception report blocks. 
A packet type (PT) field 407 contains the constant 200 to identify that the packet is an RTCP SR 
packet. A 16-bit length field 409 is provided. The synchronization source (SSRC) identifier 
field 41 1 indicates the originator of the SR packet. 

|49] A sender information section (fields 413-419) is 20 octets long and is present in every 
sender report packet. This section summarizes the data transmissions from the sender. An NTP 
timestamp field 413 is 64 bits and indicates the time when the report was transmitted. This 
timestamp field 413 may be used to calculate round -trip propagation. In addition, a RTP 
timestamp field 415 (32 bits in length) corresponds to the same time as the NTP timestamp field 
413, but in the same units and with the same random offset as the RTP timestamps in data 
packets. The timestamp fields 413 and 415 may be used for synchronization of the sources. 
1501 A sender's packet count field 417 is provided to specify the total number of RTP data 
packets that are transmitted by the sender from the period of the start-up of the transmission 
through the time the SR packet was generated. The count is reset if the sender changes its SSRC 
identifier. A sender's octet count field 419 indicates the total number of payload octets 
(exclusive of the header and padding). This field 419 can be used to estimate the average 
payload data rate. 

[51J Fields 421-435 may contain the reception report blocks. Each reception report block 
conveys statistics on the reception of RTP packets from a single synchronization source. SSRC 
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identifier fields 421, 435 correspond to the sources associated with the respective reception 
report blocks. A fraction lost field 423 specifies the fraction of RTP data packets lost from 
source SSRC since the time the previous SR or RR packet was sent; the fraction is defined as the 
number of packets lost divided by the number of packets expected. A cumulative number of 
packets lost field 425 is also supplied, and defined as the number of packets expected less the 
number of packets actually received. It is noted that packets that arriv e late are not counted as 
lost; the loss may have a negative value if there are duplicates. Also, an extended highest 
sequence number received field 427. An interarrival jitter field 429 specifies an estimate of the 
statistical variance of the RTP data packet interarrival time. 

{521 A Last SR timestamp (LSR) field 431 specifies the middle 32 bits out of 64 in the NTP 
timestamp field 413. If no SR has been received yet, the field is set to a default of zero. 
Information regarding the delay since the last SR (DLSR) is provided in a Delay Since Last SR 
field 433. The delay may be expressed in units of 1/65536 seconds between receiving the last SR 
packet from a source SSRC (in this case, the first source) and sending this reception report block. 
If no SR packet has been received yet from the first SSRC, the DLSR field 433 is set to zero. 
[53] It is noted that the format of the receiver report (RR) packet is the same as that of the SR 
packet except that the packet type field contains the constant 201 and the five words of sender 
information are omitted (these are the NTP and RTP timestamps and sender's packet and octet 
counts). As explained previously, a profile -specific extensions field 437 is also provided. 
[54] The above report is exchanged between a near end station and a far end station to report 
the quality in the communication session, according to an embodiment of the present invention. 
[551 FIG. 5 shows a flowchart of a process for providing session quality indication to a near 
end station, according to an embodiment of the present invention. In step 501 , a VOIP session is 
established between a near end station and a far end station. Next, the quality of the session is 
determined, per step 503, based upon an RTCP report, as described previously. In step 505, a 
RTPC message that is indicative of the quality of the session is transmitted to the near end 
station. The near end station then provides a visual (or audio) notification of the quality of the 
session based upon the statistics within the RTPC message, per step 507. Exemplary visual 
notifications are shown in FIGs. 6 A and 6B. 
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[T561] FIGs. 6 A and 6B show diagrams of a LED (Light Emitting Diode) type display and a 
pop-up menu, respectively, to indicate the quality of a communication session, according to an 
embodiment of the present invention. A LED display, as shown in FIG. 6A, may be [<br> 

<BR> IMPLEMENTED IN HARDWARE AS PART OF THE STATION (E . G. , 

sip PHONE) in which three different LED] segments 601,603, 605 has three 
colors to represent the degree of the quality of the communication session. For example, the 
segments 601,603, 605 may be red, yellow, and green, respectively, whereby the red segment 601 
denotes the poorest quality and the green segment 605 the best. Within each of the segments 
601,603, 605, a number of bars may be used to represent sub-levels of the quality. It is recognized 
that anv We.1 of granularitv mav he utilized to notify the near end station that the communication 
session is experiencing trouble. 

Alternatively, the LED display may be represented as part of a graphical user interface (GUI) of 
the near end station. 

[ [57] ] FIG. 6B shows another way to notify the near end station of the session quality through 
the use of a pop-up menu in graphical user interface. A pop-up menu 607, in an exemplary 
embodiment, is launched upon the quality falling below a predetermined threshold. The menu 607 
may described the cause of the problem. Additionally, the menu 607 may instruct the near end 
station of the appropriate action to take; for example, terminating the session and placing the call 
again. 

[158] ] FIG. 7 illustrates a computer system 700 upon which an embodiment according to the 
present invention can be implemented. The computer system 700 includes a bus 701 or other 
communication mechanism for communicating information, and a processor 703 coupled to the 
bus 701 for processing information. The computer system 700 also includes main memory 705, 
such as a random access memory (RAM) or other dynamic storage device, coupled to the bus 701 
for storing information and instructions to be executed by the processor 703. Main memory 705 
can also be used for storing temporary variables or other intermediate information during 
execution of instructions to be executed by the processor 703. The computer system 700 further 
includes a read only memory (ROM) 707 or other static storage device coupled to the bus 701 for 
storing static information and instructions for the processor 703. A storage device 709, such as a 
magnetic disk or optical disk, is additionally coupled to the bus 701 for storing information and 
instructions. 
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magnetic disk or optical disk, is additionally coupled to the bus 701 for storing information and 
instructions. 

[59] The computer system 700 may be coupled via the bus 701 to a display 711, such as a 
cathode ray tube (CRT), liquid crystal display, active matrix display, or plasma display, for 
displaying information to a computer user. An input device 713, such as a keyboard including 
alphanumeric and other keys, is coupled to the bus 701 for communicating information and 
command selections to the processor 703. Another type of user input device is cursor control 
715, such as a mouse, a trackball, or cursor direction keys for communicating direction 
information and command selections to the processor 703 and for controlling cursor movement 
on the display 711. 

[60] According to one embodiment of the invention, the processes associated with generation 
of a quality indicator are provided by the computer system 700 in response to the processor 703 
executing an arrangement of instructions contained in main memory 705. Such instructions can 
be read into main memory 705 from another computer- readable medium, such as the storage 
device 709. Execution of the arrangement of instructions contained in main memory 705 causes 
the processor 703 to perform the process steps described herein. One or more processors in a 
multi-processing arrangement may also be employed to execute the instructions contained in 
main memory 705. In alternative embodiments, hard -wired circuitry may be used in place of or 
in combination with software instructions to implement the embodiment of the present invention. 
Thus, embodiments of the present invention are not limited to any specific combination of 
hardware circuitry and software. 

[611 The computer system 700 also includes a communication interface 717 coupled to bus 
701. The communication interface 717 provides a two-way data communication coupling to a 
network link 719 connected to a local network 721. For example, the communication interface 
717 may be a digital subscriber line (DSL) card or modem, an integrated services digital network 
(ISDN) card, a cable modem, or a telephone modem to provide a data communication connection 
to a corresponding type of telephone line. As another example, communication interface 717 
may be a local area network (LAN) card (e.g. for Ethernet™ or an Asynchronous Transfer Model 
(ATM) network) to provide a data communication connection to a compatible LAN. Wireless 
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links can also be implemented. In any such implementation, communication interface 717 sends 
and receives electrical, electromagnetic, or optical signals that carry digital data streams 
representing various types of information. Further, the communication interface 717 can include 
peripheral interface devices, such as a Universal Serial Bus (USB) interface, a PCMCIA 
(Personal Computer Memory Card International Association) interface, etc. Although only a 
single communication interface 717 is shown, it is recognized that multiple communication 
interfaces may be employed to communicate with different networks and devices. 
[62] The network link 719 typically provides data communication through one or more 
networks to other data devices. For example, the network link 719 may provide a connection 
through local network 721 to a host computer 723, which has connectivity to a network 725 (e.g. 
a wide area network (WAN) or the global packet data communication network now commonly 
referred to as the "Internet") or to data equipment operated by service provider. The local 
network 721 and network 725 both use electrical, electromagnetic, or optical signals to convey 
information and instructions. The signals through the various networks and the signals on 
network link 719 and through communication interface 717, which communicate digital data 
with computer system 700, are exemplary forms of carrier waves bearing the information and 
instructions. 

(63] The computer system 700 can send messages and receive data, including program code, 
through the network(s), network link 719, and communication interface 717. In the Internet 
example, a server (not shown) might transmit requested code belonging an application program 
for implementing an embodiment of the present invention through the network 725, local 
network 721 and communication interface 717. The processor 703 may execute the transmitted 
code while being received and/or store the code in storage d evice 79, or other non-volatile 
storage for later execution. In this manner, computer system 700 may obtain application code in 
the form of a carrier wave. 

[64] The term "computer-readable medium" as used herein refers to any medium that 
participates in providing instructions to the processor 703 for execution. Such a medium may 
take many forms, including but not limited to non-volatile media, volatile media, and 
transmission media. Non -volatile media include, for example, optical or magnetic disks, such as 
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storage device 709. Volatile media include dynamic memory, such as main memory 705. 
Transmission media include coaxial cables, copper wire and fiber optics, including the wires that 
comp^e bus 701. Transmission media can also take the form of acoustic, optical, or 
electromagnetic waves, such as those generated during radio frequency (RF) and infrared (ER) 
data communications. Common forms of computer-readable media include, for example, a 
floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD -ROM, 
CDRW, DVD, any other optical medium, punch cards, paper tape, optical mark sheets, any other 
physical medium with patterns of holes or other optically recognizable indicia, a RAM, a PROM, 
and EPROM, a FLASH-EPROM, any other mem ory chip or cartridge, a carrier wave, or any 
other medium from which a computer can read. 

[65] Various forms of computer-readable media may be involved in providing instructions to a 
processor for execution. For example, the instructions for carrying out at least part of the present 
invention may initially be borne on a magnetic disk of a remote computer. In such a scenario, 
the remote computer loads the instructions into main memory and sends the instructions over a 
telephone line using a modem. A modem of a local computer system receives the data on the 
telephone line and uses an infrared transmitter to convert the data to an infrared signal and 
transmit the infrared signal to a portable computing device, such as a personal digital assistance 
(PDA) and a laptop. An infrared detector on the portable computing device receives the 
information and instructions borne by the infrared signal and places the data on a bus. The bus 
conveys the data to main memory, from which a processor retrieves and executes the 
instructions. The instructions received by main memory may optionally be stored on storage 
device either before or after execution by processor. 

[66] Accordingly, the present invention provides a feedback mechanism, which may be visual 
or audio, is introduced to notify a near end station of the quality of a voice communication 
session over a data network. The feedback mechanism is based upon the quality statistics that 
are convey via a real-time communications protocol, such as Real-time Transport Control 
Protocol. The above approach advantageously enhances call processing over the data network. 
[67| While the present invention has been described in connection with a number of 
embodiments and implementations, the present invention is not so limited but covers various 
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obvious modifications and equivalent arrangements, which fall within the purview of 
appended claims. 
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CLAIMS 

WHAT IS CLAIMED IS: 

y^y^ 1. A method for supporting a communication session between^a^ear end stotiqr^and a 
far end station over a data network, the method comprising: ^ 

determining quality o f the communication session in a direction of the near end station to 
the far end station; and * 

transmitting a message according to a p rescribed protoco l to the near end statio n to notify 
the near end station of the quality of the communication session, wherein the prescribed protocol 
supports real-time data exchange. 

2. A method according to claim 1, wherein the prescribed protocol is the Real-Time 
Transport Control Protocol (RTCP). 

3. A method according to claim 1, wherein the near end station provides at least one of a 
visual indication of the quality of the communication session and an audio indicatio n of the 
quality of the communication session based upon the message. 

4. A method according to claim 3, wherein the visual indication includes at least one of a 
LED (Light Emitting Diode)-type display, and a pop-up menu. 

5. A method according to claim 1, wherein the near end station and the far end station 
communicate using a multimedia-based protocol that includes at least one of a Session Initiation 
Protocol, and H.323 protocol. 

/ 6. A network devic e for supporting a communication session between a near end station 
and a far end station over a data network, the device comprising: 

a processor configured to determine quality of the communication session in a direction 
of the near end station to the far end station; and 

a communications interface coupled to the processor and configured to transmit a 
message according to a prescribed protocol to the near end station to notify the near end station 
of the quality of the communication session, wherein the prescribed protocol supports real-time 
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data exchange. 

7. A network device according to claim 6, wherein the prescribed protocol is the Real- 
Time Transport Control Protocol (RTCP). 

8. A network device according to claim 6, wherein the near end station provides at least 
one of a visual indication of the quality of the communication session and an audio indication of 
the quality of the communication session based upon the message. 

9. A network device according to claim 8, wherein the visual indication includes at least 
one of a LED (Light Emitting Diode)-type display, and a pop -up menu. 

10. A network device according to claim 6, wherein the near end station and th e far end 
station communicate using a multimedia-based protocol that includes at least one of a Session 
Initiation Protocol and H.323 protocol. 

11. A system for providing telephony services over a data network, the system 
comprising: 

a first station having connectivity with the data network and being configured to initiate 
establishment of a communication session over the data network; and 

a second station configured to acknowledge the communication session with the first 
station, wherein the second station is further configured to determine quality of the 
communication session in a direction from the second station to the first station, and to transmit a 
message according to a prescribed protocol to the first station to notify the first station of the 
quality of the communication session, the prescribed protocol supporting real-time data 
exchange. 

12. A system according to claim 11, wherein the prescribed protocol is the Real-Time 
Transport Control Protocol (RTCP). 

13. A system according to claim 1 1, wherein the first station provides at least one of a 
visual indication of the quality of the communication session and an audio indication of the 
quality of the communication session based upon the message. 

14. A system according to claim 13, wherein the visual indication includes at least one of 
a LED (Light Emitting Diode)-type display, and a pop-up menu. 

15. A system according to claim 1 1, wherein the first station and the second station 
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communicate using a multimedia -based protocol that includes at 1 east one of a Session Initiation 
Protocol and H.323 protocol. 



16. A device for supporting a communication session between a near end station and a 



far end station over a data network, the device comprising: 

means for determining quality of the communication session in a direction of the near end 
station to the far end station; and 

means for transmitting a message according to a prescribed protocol to the near end 
station to notify the near end station of the quality of the communication session, wherein the 
prescribed protocol supports real-time data exchange. 

17. A device according to claim 16, wherein the prescribed protocol is the Real-Time 
Transport Control Protocol (RTCP). 

18. A device according to claim 16, wherein the near end station provides at least one of 
a visual indication of the quality of the communication session and an audio indication of the 
quality of the communication session based upon the message. 

19. A device according to claim 18, wherein the visual indication includes at least one of 
a LED (Light Emitting Diode)-type display, and a pop-up menu. 

20. A device according to claim 16, wherein the near end station and the far end station 
communicate using a multimedia -based protocol that includes at least one of a Session Initiation 
Protocol and H.323 protocol. 



21. A computer-readable medium carrying one or more sequences of one or more 



instructions for supporting a communication session between a near end station and a far end 
station over a data network, the one or more sequence s of one or more instructions including 
instructions which, when executed by one or more processors, cause the one or more processors 
to perform the steps of: 

determining quality of the communication session in a direction of the near end station to 
the far end station; and 

transmitting a message according to a prescribed protocol to the near end station to notify 
the near end station of the quality of the communication session, wherein the prescribed protocol 
supports real-time data exchange. 
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22. A computer-readable medium according to claim 21, wherein the prescribed protocol 
is the Real-Time Transport Control Protocol (RTCP). 

23. A computer-readable medium according to claim 21 , wherein the near end station 
provides at least one of a visual indication of the quality of the communication session and an 
audio indication of the quality of the communication session based upon the message. 

24. A computer-readable medium according to claim 23, wherein the visual indication 
includes at least one of a LED (Light Emitting Diode) -type display, and a pop-up menu. 

25. A computer-readable medium according to claim 21, wherein the near end station 
and the far end station communicate using a multimedia-based protocol that includes at least one 
of a Session Initiation Protocol and H.323 protocol. 
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